home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group02b.txt / 000055_icon-group-sender_Fri Oct 4 07:38:42 2002.msg < prev    next >
Internet Message Format  |  2003-01-02  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g94Ecds13221
  4.     for icon-group-addresses; Fri, 4 Oct 2002 07:38:39 -0700 (MST)
  5. Message-Id: <200210041438.g94Ecds13221@baskerville.CS.Arizona.EDU>
  6. From: "Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid>
  7. X-Newsgroups: comp.lang.icon
  8. Subject: Re: Icon Wish List
  9. Date: Fri, 04 Oct 2002 01:24:49 -0400
  10. Mail-Copies-To: nobody
  11. X-Cise: tanbanso@iinet.net.au
  12. X-CompuServe-Customer: Yes
  13. X-Coriate: admin@interspeed.co.nz
  14. X-Ecrate: tanandtanlawyers.com
  15. X-Punge: Micro$oft
  16. X-Sanguinate: themvsguy@email.com
  17. X-Terminate: SPA(GIS)
  18. X-Tinguish: Mark Griffith <markgriffith@rocketmail.com>
  19. X-Treme: C&C,DWS
  20. X-Newsreader: MR/2 Internet Cruiser Edition for OS/2 v2.31a/31 
  21. X-Complaints-To: abuse@supernews.com
  22. To: icon-group@cs.arizona.edu
  23. Errors-To: icon-group-errors@cs.arizona.edu
  24. Status: RO
  25.  
  26.  
  27. In <ambeg5$4gk5e$1@ID-79573.news.dfncis.de>, on 09/19/2002
  28.    at 12:57 PM, "Andrew Hamm" <ahamm@mail.com> said:
  29.  
  30. >Since Icon is completely free with variable types and call arguments,
  31. >it follows that class members should not be typed, 
  32.  
  33. No. The class is the type.
  34.  
  35. >and overloaded methods do
  36. >not make sense either
  37.  
  38. They make perfect sense if you allow subclasses and such.
  39.  
  40. >one name, one method
  41.  
  42. Too restrictive, and destroys some of the value of OO programming.
  43.  
  44. >What about member privacy? With the 1 file, 1 class model, it does
  45. >become possible to add a "private" keyword for class methods,
  46. >members and statics. If marked as private, the member is not visible
  47. >outside the file. However, that does not fit at all with the dynamic
  48. >typing of Icon.
  49.  
  50. Yes it does. Don't confuse the scope of the name with the lifetime of
  51. the object.
  52.  
  53. >However,
  54. >that does not fit at all with the dynamic typing of Icon.
  55.  
  56. It fits in perfectly. All that changes is that there are more possible
  57. types.
  58.  
  59. >How do you know the type of a particular variable at any one time?
  60.  
  61. The same way as in any other language with dynamic types.
  62.  
  63. >To do this "properly" on UNIX, the compiler could probably write to
  64. >a tmp file (not linked into a directory) and then hand the open file
  65. >handles off to a cooperating iconx which can slurp up the icode from
  66. >the tmp file handles and then close them, resulting in their
  67. >deallocation. 
  68.  
  69. Bletch!
  70.  
  71.  
  72. -- 
  73.      Shmuel (Seymour J.) Metz, SysProg and JOAT
  74.      Atid/2, Team OS/2, Team PL/I
  75.  
  76. Any unsolicited commercial junk E-mail will be subject to legal
  77. action.  I reserve the right to publicly post or ridicule any
  78. abusive E-mail.
  79.  
  80. I mangled my E-mail address to foil automated spammers; reply to
  81. domain Patriot dot net user shmuel+news to contact me.  Do not
  82. reply to spamtrap@library.lspace.org
  83.  
  84.